This invention describes a xe2x80x9cjunction managerxe2x80x9d and process that improve upon the junction object interconnect technology described in Program Object Interconnection and Method, my co-pending, commonly assigned patent application, Ser. No. 08/417,582, filed Apr. 6, 1995.
1. Field of the Invention
This invention relates generally to computer programming methods and, in particular, to object oriented programming and to methods of connecting independent program objects for communicating or for sharing data in such programming constructs.
2. Background of the Invention
OMG""s CORBA (Common Object Request Broker Architecture) provides for distribution of interobject data and communication based on remote procedure calls (RPCs). In this model, one program object makes a method call against another, possibly remote, program object. The called, possibly remote, object executes the method and returns results to the caller. This model is simple and eases the transition from uniprocessor to multiprocessor programming environments, but it suffers from inherent latency. Unless the calling object uses complicated, asynchronous callbacks, it must wait for the called object to perform the requested task and respond.
U.S. Pat. No. 5,396,630 commonly assigned to the Assignee of the present application, is incorporated herein by reference as an example of the registry and messaging approach described above, specifically for an object request broker type of object programming communication environment.
In my aforementioned patent application, state changes are propagated among object-connecting junctions. When a state change occurs at one object""s junction, the new state is sent to each connected object""s junction. Junctions for objects are connected in a circularly-link list. Thus, the junctions form a logical ring for sharing data, such as changes of state of one or more objects.
Using my prior patent application, when N object junctions are connected, propagating state changes or data requires that Nxe2x88x921 messages be sent (one to each junction, excluding the junction initiating the propagation), and each junction participates in forwarding the data or message.
It is an object of this invention to provide an improved mechanism and process for eliminating multiple sending and exchanging of synchronization and state messages among interconnectable program objects.
It is a further object of this invention to provide for an improved object request broker function without either the broker entity or the need for the messaging overhead associated with prior art program object request brokers.
The junction manager in the present invention eliminates the need for a separate request broker or manager and eliminates, as well, the need for each junction to propagate each state change. Instead, the state change of each program object (hereinafter simply referred to as xe2x80x9cobjectxe2x80x9d) to be interconnected is reported once by the junction manager function process either located in or used by each object desiring to do so, to a shared memory space. xe2x80x9cProcessesxe2x80x9d in each object""s junction manager (we use the term process to represent processes, threads or objects themselves) which are thus logically connected or xe2x80x9cjoinedxe2x80x9d, and which may depend on one another, then query the shared memory space to obtain information about the state of a junction with another object that is of interest to them. The junction manager function used by the object services each query by accessing and returning from the shared memory space the next chronologically posted state that the requesting process has not previously seen. For example, if the state of the junction has changed from S0 to S1 to S2, the current state is S2; but, if a process P has not queried the junction""s state since it was S0, then the junction manager function of the requesting process P would return S1 to process P""s request. S2 would be returned on the P""s subsequent query.
Processes can access and read only the state changes for a queried junction that occur after the processes attach to an object""s junction by accessing shared memory. In the example above, if a process P2 attached to a junction after the state changed to S2, but before the junction again changed its state, then P2""s first query via its junction manager process would return S2; P2 would never see S0 or S1.
Processes, such as objects, can perform a number of operations when executing sub-processes to act as junction managers as listed briefly below:
Create a new junction with an initial state and no attached processes.
Attach to (i.e., access in shared memory) another object""s junction data. Once a process has attached to a junction""s data, it is eligible to query or alter the junction""s data state; however, unattached process can neither query nor alter
a junction""s state data.
Set the junction state data.
Query the junction""s state data.
Unlink a junction from an object. After unlinking, a process can neither query nor alter a junction""s state data.
Destroy a junction entirely.